Computer applications such as a word processing application 115 executing on a client device 105 (see FIG. 1) often produce graphics that need to be rendered to pixel colour values for output to a rendering device such as 135 in FIG. 1 which can, for example, be a display or a printer.
Such computer applications, referred to hereinafter merely as “computer applications”, generally specify these graphics, referred to hereinafter as high-level graphics, using a high-level page description language (PDL), such as PostScript or PDF by Adobe, or the Open XML Paper Specification (OpenXPS). Alternatively, the computer application may specify these high-level graphics using a graphics interface, such as Microsoft's GDI or GDI+.
The high-level graphics to be rendered are described using graphic objects or commands, referred to hereinafter as high-level graphic commands. In order for the rendering device 135 to render the objects associated with these high-level graphic commands, the rendering device 135 needs to understand all the high-level graphic commands provided by each PDL or interface that the rendering device is intended to support.
In addition, the rendering device may need to perform a large amount of processing, including scan-conversion and compositing. To process the high-level graphic commands efficiently, the rendering device typically needs a large amount of processing power and/or memory.
One method of avoiding the need for the rendering device to support high-level graphic commands in multiple formats is to convert the high-level graphic commands to a set of lower-level commands that are understood by the rendering device. This is usually done using a driver software application, referred to hereinafter as a driver, which is installed on the computer 105 upon which the computer application 115 is running. The driver converts the high-level graphic commands produced by the computer application 115 into a format understood by the rendering device 135. However this requires that a driver be installed on every computer which will communicate with the rendering device.
One method described in the prior art that does not require a driver executing on the computer 105 running the computer application 115 uses a computer application running on a remote server computer 120 known as a cloud server or a platform service device. In this method, the rendering device 135 receives, from the computer application 115 executing on the client device 105, information specifying what is to be rendered to a page. This information, referred to hereinafter as “page data”, is in a high-level graphic command format. The rendering device 135 sends the page data to the cloud server 120, which translates it into a format understood by the rendering device 135. This has the advantage that no driver is required on the client device 105, and furthermore, a large amount of processing typically performed by the rendering device 135 to render the page may be performed on the cloud sever 120.
However this approach has several disadvantages. Firstly, if the high-level graphic commands that need to be sent to the cloud server 120 comprise a large amount of data, particularly image data, the page may be slow to render, as the page data needs to be first sent to the cloud server 120, and then re-encoded and sent back to the rendering device 135. A second disadvantage is that the page data in the page may be sensitive or confidential, and accordingly the page data should not be transmitted to the remote server 120 for security reasons. For example, it is clear that proprietary information which cannot be shared outside of an organisation should not be sent to the remote server 120 for rendering, in order to preclude the proprietary information running the risk of being accessed without authority by a third party.